Feat: AES LightEngine CCM Mode - #126

…XOF128/CXOF128) implementing AEADCipherEncryptor/AEADCipherDecryptor via AsconAead128Encryptor/AsconAead128Decryptor, with HashFactory/XOFFactory registration and CLI wiring including a TaggedDecryptor-based decrypt stream

…OF/XOFSqueezer API and updated factory/CLI/tests/benches to compile against the new API (bcgit#119)

…/officialfrancismendoza/119-core-aead-cipher

…CLI thread, and fix a broken intra-doc link (bcgit#119)

Review follow-ups on the head of bcgit#120; no behaviour changes.

- cli/src/main.rs, cli/src/ascon_cmd.rs: the ascon-aead128 command's help and module docs still
  described the pre-nonce-prefix format ("output = ciphertext||tag") after the command started
  generating a nonce and writing it as the first 16 bytes of the stream. They now spell the
  convention out in both directions, the way aes128-ctr's help does for its own nonce, and say what
  --nonce/--nonce-file turn off -- the part a user gets wrong, since feeding a prefixed ciphertext
  to "--decrypt --nonce ..." decrypts garbage and only then fails the tag check. The two encrypt
  paths each gain a line saying which API they drive and why the explicit-nonce one cannot use the
  AEADCipherEncryptor pair (do_encrypt_init generates the nonce by construction).
- cli/src/main.rs: fn main's 8 MiB thread gains a comment for the constraint it exists for. It is
  load-bearing: with it removed and `ulimit -s 1024`, every subcommand -- sha3-256 as much as
  ascon-aead128 -- overflows during argument parsing in a debug build, before any algorithm runs.
- crypto/ascon/src/lib.rs: [`ascon_aead128::AsconAead128Decryptor::do_decrypt_final`] does not
  resolve, because do_decrypt_final is an AEADCipherDecryptor method rather than an inherent one,
  so `cargo doc` warned and published a dead link. Points at the trait method instead.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…#119)

The entry carried the pre-remediation run, flagged as such ("20 missed before the XOF/CXOF
boundary-test additions"). Re-measured on this head with `cargo mutants -p bouncycastle-ascon
--test-package bouncycastle-ascon --jobs 3 --timeout 120`, with bc-test-data reachable from the
copied tree and a config whose examine_globs block is removed: 735 mutants, 618 caught, 111
unviable, 6 missed. The six are the known equivalences already commented at their sites -- the
sponge absorb/squeeze boundaries and the two disjoint-bit `|` -> `^` in set_state_byte -- so the
14 real survivors that run found in the XOF/CXOF Hash view are dead.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…eded by the AEADCipherEncryptor/AEADCipherDecryptor split (bcgit#119)

AEADCipher was the single-type AEAD trait this issue exists to split. It had no implementor on the
base branch and its conformance suite had nothing to run against; this PR was about to give it its
first and only implementor, on AsconAead128, in the same change that introduces the pair meant to
replace it. That would have left the library with two parallel AEAD abstractions and Ascon-AEAD128
with four public one-shot encrypt surfaces. Deleted instead:

- crypto/core/src/traits.rs: the trait itself (encrypt/encrypt_out/decrypt/decrypt_out, the
  aead_* pair, do_aead_encrypt_final/do_aead_decrypt_final). The AEADCipherEncryptor doc that
  contrasted its tag placement with this trait's now just points at tagged_aead.
- crypto/core-test-framework/src/symmetric_ciphers.rs: TestFrameworkAEADCipher::test and
  ::test_plain_one_shots, the suites for it. The struct keeps test_encryptor_decryptor and
  test_buffering_toy, which exercise the pair.
- crypto/ascon/src/ascon_aead128.rs: the impl, and the module-doc sentence that justified the
  newtype pair by pointing at it.

Test coverage is kept where it was about Ascon rather than about the trait: the chunk-boundary
sweep and the wrong-tag rejection now drive the inherent do_encrypt_final/do_decrypt_final (they
only used the trait for its finalizers), and the undersized-buffer suite is rewritten against the
inherent one-shots, whose own length checks -- including the 16-byte-ciphertext and oversized-buffer
boundaries that must NOT be rejected -- were previously reached only through the trait. The three
tests that were about the deleted code (the std Vec wrappers, the plain view's
DecryptionFailed remapping, the AEADCipher framework conformance call) go with it.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ion figures (bcgit#119)

Deleting the trait and its suites takes bouncycastle-ascon from 735 mutants to 655: 558 caught, 91
unviable, 6 missed, the same six known equivalences as before, so the tests ported onto the
inherent one-shots hold the coverage the deleted trait's tests had.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…ag layout on the AEAD traits, and address the remaining API-shape review points (bcgit#119)

The `tagged_aead` adapter pair is gone; what it did belongs to the traits themselves.

- crypto/core/src/traits.rs: AEADCipherEncryptor gains `tagged_encrypt` (one-shot into
  `ciphertext || tag`), `tagged_do_aead_encrypt_final` (streaming: flush, then append the tag) and
  `tagged_encrypt_out_len`; AEADCipherDecryptor gains `tagged_decrypt`,
  `tagged_do_aead_decrypt_final` (streaming: the tail is leftover ciphertext followed by the tag)
  and `tagged_decrypt_out_max_len`. All are defaults over the existing methods, so every
  implementor gets both layouts and neither has to be bolted on by a wrapper type that cannot
  express a buffering cipher's lengths (the `FINAL_LEN = 0` restriction TaggedEncryptor and
  TaggedDecryptor carried).
- crypto/core/src/tagged_aead.rs is deleted, with its module declaration and every use of it.
  crypto/core/tests/aead_tagged_tests.rs keeps the toy AEAD the deleted module's in-`src` tests
  used and points it at the new methods: round trip at every length crossing `TAG_LEN`, every
  chunking, tampering, a stream that ends before a whole tag, and every undersized buffer.
- crypto/core-test-framework: the AEAD suite now checks the inline layout for every implementor
  (one-shot against streaming, and a too-short tail as DecryptionFailed), and the buffering toy
  checks it where FINAL_LEN > 0, which is where `tagged_do_aead_encrypt_final` has to flush and
  append in one call. Its short-buffer probe on the decryptor now feeds the decryptor its own
  ciphertext rather than the plaintext, and uses the ciphertext's length.
- crypto/ascon: `AsconAead128::new`'s `for_encryption: bool` is no longer public API --
  `new_encrypting` / `new_decrypting` name the direction, and the bool constructor they share is
  private. The crate docs gain a `tagged_*` example.
- cli/src/ascon_cmd.rs: both directions drive the trait pair, holding the tag back by hand on the
  way in, which is what the adapter did for it. A failed `do_encrypt_init`/`do_decrypt_init` --
  the RNG or the key material -- now prints an error and exits rather than panicking, as
  block_mode_cmd.rs does for the same call, and the remaining unwraps carry their `infallible:`
  notes.
- crypto/core/src/traits.rs also: the allocating one-shot's three-part return is now the named
  `AEADEncrypted<NONCE_LEN, TAG_LEN>` (clippy `type_complexity`), and `decrypt_out` /
  `encrypt_out_rng` get the same "an implementor with FINAL_LEN > 0 must override this" note
  `encrypt_out` already had.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…nges (bcgit#119)

661 mutants, 558 caught, 97 unviable, 6 missed -- the same six known equivalences (the sponge
absorb/squeeze boundaries and the two disjoint-bit `|` -> `^` in set_state_byte). The count moves
from 655 with the new_encrypting/new_decrypting constructors.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… in the tagged AEAD defaults (bcgit#119)

`cargo mutants -p bouncycastle-core -f crypto/core/src/traits.rs --re
'AEADCipherEncryptor|AEADCipherDecryptor' --test-package bouncycastle-core --test-package
bouncycastle-ascon` reported 116 mutants, 91 caught, 19 unviable, 6 missed. Four of the six were
real: the buffer guards could be weakened without a test noticing, because a too-short buffer is
rejected either by the guard or by the `do_update_out` behind it, and both report
IncorrectOutputBufferLength with the same length -- so the probes could not tell which had fired.

- crypto/core/tests/aead_tagged_tests.rs: `tagged_do_aead_decrypt_final` with a buffer of exactly
  `needed` must succeed. Kills `plaintext.len() < needed` -> `<=` and -> `==`.
- crypto/core-test-framework: the buffering toy now finishes from a tail that still holds
  ciphertext (TAG_LEN + 4 bytes) into an exactly-sized buffer, which is what makes
  `update_out_len(..) + FINAL_LEN` observable -- with a generous buffer any arithmetic there would
  do. Kills `+ FINAL_LEN` -> `* FINAL_LEN`. The AEAD suite also feeds `encrypt_out_rng` a buffer
  with room to spare, so its own guard cannot be flipped to `>` unnoticed.

The re-run is 116 mutants, 95 caught, 19 unviable, 2 missed; the two are `written + final_len` ->
`written - final_len` in `encrypt_out_rng`, equivalent while every implementor has FINAL_LEN = 0.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…defaults (bcgit#119)

The ascon crate's numbers were already there; the pair's own defaults in core were only in
f376c14's commit message. 116 mutants, 95 caught, 19 unviable, 2 missed.

Assisted-by: Claude:claude-opus-5

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…25-AES-lightengine-CCM-mode' into feature/officialfrancismendoza/125-AES-lightengine-CCM-mode

Merged origin CCM history into updated xof-cshake CCM branch

…or a short inline C, empty update keeps the AAD phase open, per-side capacity messages, hoisted keystream scratch

* CcmDecryptor now carries the same NONCE_LEN >= 12 assertion as
  CcmEncryptor (moved into CcmBuffer and run from every entry point of
  both, one-shots included), so a parameter set compiles for both sides
  or neither; compile_fail doctest added for the decryptor.
* An inline ciphertext shorter than TAG_LEN is DecryptionFailed from all
  three inline entry points (Ccm::decrypt previously said GenericError),
  the variant SymmetricCipherDecryptor::do_final specifies for a
  malformed ciphertext.
* CcmBuffer::do_update_out with an empty slice is a no-op and no longer
  closes the AAD phase, matching the trait's empty-AAD-at-any-point rule.
* The over-capacity message names the caller's real bound: the encryptor
  is limited to FINAL_LEN - TAG_LEN, the decryptor to FINAL_LEN.
* The batched keystream Secret is held per apply_keystream call instead
  of per 2/4-block batch, the same shape Ctr now uses.
* Docs: short tags are justified by Appendix C.1/C.2 (Tlen=32, 48), not
  the ACVP set, which has only 96- and 128-bit tags; the AAD sharing
  FINAL_LEN's bound is stated on CcmEncryptor with the sizing rule.

Tests: sp800_38c_tests gains an_empty_update_does_not_close_the_aad_phase,
extends the short-ciphertext test to all three entry points, and pins the
encryptor's message to its bound. SP 800-38C Appendix C parameters
verified against the downloaded PDF.

Assisted-by: Claude:claude-fable-5-1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…ptor too, and the AAD shares FINAL_LEN's bound

Assisted-by: Claude:claude-fable-5-1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

…n the q limit on decrypt as well as encrypt

A --nonce-file written with echo rather than echo -n is a valid 13-byte
nonce, so it was silently accepted as a different nonce from the 12 bytes
intended; the bytes are still used as they are (stripping would collapse
two distinct nonces into one), but stderr now says so and gives the
remedy. The decrypt arm printed the raw Debug form of Ccm::new's payload
limit error; both arms now go through one helper that reports the payload
length, q and the limit.

Assisted-by: Claude:claude-fable-5-1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

… claimed to, and record what it measures

bench_buffering_* called the one-shots, which CcmEncryptor/CcmDecryptor
override to bypass the buffer, so the "3 * BUFFER_LEN" the header claimed
was never exercised, and BUFFER_LEN was the pre-rename name. The benches
now drive do_*_init -> do_update_out -> do_final (and the detached final),
the one-shot is kept as its own bench for the "bypasses the buffer" claim,
FINAL_LEN is 16 KiB so every path clears massif's ~7.7 KB start-up floor,
and the message is pinned through a black_box reference so the compiler
places it identically in every bench. Measured figures are in the header:
the one-shot is within 1.3 KB (the DRBG) of the direct path, and the
streaming path costs about 7 * FINAL_LEN, not 3, because each consuming
final takes the 2 * FINAL_LEN value by value.

Assisted-by: Claude:claude-fable-5-1
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Ccm and CcmEncryptor are imported into crypto/aes/src/ccm.rs, so
[`Ccm`](bouncycastle_modes::Ccm) and its CcmEncryptor twin resolve without
the target, and `cargo doc` with -D warnings failed on them with
rustdoc::redundant_explicit_links.

Assisted-by: Claude:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…ne the table supports

bench_streaming_encrypt's doc said ~7 * FINAL_LEN above
bench_direct_encrypt_detached, but the measured 134 968 B is ~6.1x above
that bench (which also holds a ciphertext array) and ~7.2x above the
message array alone, which is how the module header states it. The
decrypt bench holds both the message and the sealed array, and its ~7x
(149 976 B, ~7.15x) is against the two of them, not the sealed array
alone. No figures change.

Assisted-by: Claude:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>